先畫圖，再選工具

我看過不少 AI 資料防護的提案，第一頁就是產品架構圖：左邊一個 Guardrail 方塊、右邊一個 LLM 方塊，中間一條箭頭。這種圖的問題是它把最關鍵的資訊藏起來了——資料在每一段是明文還是密文？那一段的儲存體在哪裡？誰有權限讀？

所以今天先做一件很不性感的事：把法務部這個場景的資料流，一段一段拆開。

完整資料流：七段

[1] 文件上傳
      ↓
[2] 格式解析 / OCR
      ↓
[3] PII 偵測
      ↓
[4] 去識別化 ──→ [Token Vault]（地端）
      ↓
[5] 送出至 LLM（行外）
      ↓
[6] 回應接收與檢查
      ↓
[7] 授權還原 ←──── [Token Vault]
      ↓
   使用者看到結果

逐段來看，重點是每一段的三個屬性：資料狀態（明文／去識別）、儲存位置、可存取者。

[1] 文件上傳。 明文。這一段資料仍在行內。要注意的是暫存：使用者上傳的原始檔存在哪？很多實作會丟一個暫存目錄就忘了它，那個目錄後來變成一個沒人管的明文個資倉庫。原則是原始檔要嘛不落地，要嘛落地在跟正式文件管理系統同等級的加密儲存區，並且有生命週期政策。

[2] 格式解析／OCR。 明文。PDF 抽文字、DOCX 解 XML、掃描件走 OCR。這一段如果 OCR 用的是雲端服務，那你的個資在偵測之前就已經出行了——這是一個很常見的架構破口，我會在 D15 專門處理。

[3] PII 偵測。 明文。這是整條管線裡計算最重、也最容易出錯的一段。偵測不到的個資會直接原樣送出去。

[4] 去識別化。 明文進、去識別出。Token Vault 在這裡被寫入：原值與 Token 的對應關係存進去。這是整個架構裡風險最集中的一點——Vault 被拿走，等於所有去識別化都白做。它必須在地端、必須加密、必須跟應用服務的權限完全分離。

[5] 送出至 LLM。 去識別化資料。這一段是唯一離開行內邊界的。理論上就算被完整攔截，攔到的也是「TW_ID_a7f3c9」而不是身分證字號。理論上。

[6] 回應接收與檢查。 去識別化資料。模型回來的內容裡應該只有 Token。但要檢查——因為模型可能會產生一個看起來像個資的東西（幻覺產生的假身分證字號），也可能被誘導吐出 system prompt 或檢索到的其他內容。這一段需要輸出側的護欄。

[7] 授權還原。 去識別化進、明文出。只有這一段會反向查詢 Vault。這是全流程唯一一次「把個資變回來」的動作，所以它必須是最嚴格的：需要獨立的授權、需要記錄 who／what／when／why、需要能事後稽核。

三個邊界

把上面七段收斂一下，真正重要的是三條線：

邊界一：地端／雲端。 落在 [4] 和 [5] 之間。這條線的左邊是明文，右邊是去識別化資料。這條線的技術實作品質，決定了整個架構成不成立。

邊界二：應用／Vault。 Vault 不能是應用程式的一張資料表。應用服務的身分不應該有直接讀取 Vault 的權限，還原必須經過一個獨立的授權服務。這條線如果沒切開，等於做了一把鎖然後把鑰匙掛在鎖上。

邊界三：一般存取／還原授權。 [7] 跟其他所有段落是不同的權限層級。日常使用 LLM 的律師，不應該自動具備還原個資的權限。

誰能碰什麼：先把角色列出來

在寫任何一行程式之前，先把角色矩陣列清楚。這份表格後面在 D19 做 RBAC 實作時會直接變成 IAM 政策：

最後一列常被質疑：系統管理員為什麼全部都是叉？

因為系統管理員需要的是「讓系統跑起來」的權限，不是「讀資料」的權限。這兩件事在雲端環境裡是可以分開的（服務帳號、CMEK、存取核准），在地端也可以透過職務分離做到。如果你的架構做不到這件事，那你的個資保護上限就是「相信系統管理員」——這在金融業的稽核報告裡是寫不過去的。

還有一個容易漏掉的角色：開發與測試人員。他們在非正式環境會拿到什麼資料？如果測試環境用的是正式資料的複本，那前面六段做的所有事情都繞過了。

落到實作：一張決策清單

在進到技術之前，這幾個問題必須先有答案，而且是業務單位跟資安一起決定，不是工程師自己決定：

1. 原始文件要不要落地？落地多久？
2. OCR 在地端還是雲端？如果是雲端，怎麼處理「偵測前就出行」的問題？
3. Token 是永久有效還是隨案件／session 失效？
4. 還原是逐筆授權還是整份授權？
5. 偵測引擎異常時，系統要全擋（fail-closed）還是放行原文（fail-open）？
6. 稽核日誌保存多久？誰有權讀？

第 5 題我在 D21 會單獨寫一天，因為它是那種平常沒人在意、出事時決定損害規模的設計。

明天把這張資料流圖轉成威脅模型，看看攻擊者會從哪一段下手。先劇透結論：不是從 LLM。

關於作者

我是 Fngi，專注在 AI 資安、LLM 紅隊與 AI 治理框架落地。這個系列的每日更新，以及平常的 AI 攻防筆記、實驗過程與研討會現場，會同步發在 IG：

@aid3fend

有想討論的架構細節或不同意見，留言或私訊都歡迎。